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A  Real-Time 
Locking  Protocol 


Abstract:  When  a  database  system  is  used  in  a  real-time  application,  the  concur¬ 
rency  control  protocol  must  satisfy  not  only  the  consistency  of  shared  data  but 
also  the  timing  constraints  of  the  application.  In  this  paper,  we  examine  a  priority- 
driven  two-phase  lock  protocol  called  the  read-  or  write-priority  ceiling  protocol. 
We  show  that  this  protocol  is  free  of  deadlock,  and  in  addition  a  high-priority  trans¬ 
action  can  be  blocked  by  lower  priority  transactions  for  at  most  the  duration  of  a 
single  embedded  transaction.  We  then  evaluate  system  performance  experimen¬ 
tally. 


1.  Introduction 

In  a  real-time  database  context,  concurrency  control  protocols  must  not  only  maintain  the 
consistency  constraints  of  the  database  but  also  satisfy  the  timing  requirements  of  the  trans¬ 
actions  accessing  the  database. 

Both  concurrency  control  [2, 3, 4,  5,  7, 16, 17, 18,  20,  21,  23,  26]  and  real-time  scheduling 
algorithms  [10, 11, 13, 14, 15, 19,  22,  27]  are  active  areas  of  research  in  their  own  right.  It 
may  seem  that  the  development  of  a  real-time  locking  protocol  is  a  simple  matter  of  combin¬ 
ing  priority  scheduling  with  a  locking  protocol.  For  example,  we  may  require  each  trans¬ 
action  to  use  a  well-known  concurrency  protocol  such  as  the  two-phase  lock  protocol  [6]  and 
assign  priorities  to  transactions  according  to  some  well-known  scheduling  algorithms  such 
as  the  earliest  deadline  algorithm  [19].  Next,  we  process  transactions  in  priority  order.  Un¬ 
fortunately,  such  an  approach  may  lead  to  unbounded  priority  inversion,  in  which  a  high- 
priority  task  would  wait  for  lower  priority  tasks  for  an  indefinite  period  of  time. 

Example  1 :  Suppose  Tv  T2,  and  T3  are  three  transactions  arranged  in  descending  order  of 
priority,  with  T1  having  the  highest  priority.  Assume  that  transaction  T1  and  T3  share  the 
same  data  object  O.  Suppose  that  at  time  f,  transaction  T3  obtains  a  write-lock  on  O.  Dur¬ 
ing  the  execution  of  T3,  the  high-priority  task  T,  arrives  and  attempts  to  read-lock  the  object 
O.  Transaction  T1  will  be  blocked,  since  O  is  already  write-locked.  We  would  expect  that 
Tv  being  the  highest  priority  transaction,  will  be  blocked  no  longer  than  the  time  for  T3  to 
complete  and  unlock  O.  However,  the  duration  of  blocking  may,  in  fact,  be  unbounded.  This 
is  because  transaction  T3  can  be  preempted  by  the  intermediate-priority  transaction  T2  that 
does  not  need  to  access  O.  The  preemption  of  T3,  and  hence  the  blocking  of  T1 ,  will  con¬ 
tinue  until  T2  and  any  other  pending  intermediate-priority  level  transactions  are  completed. 

The  blocking  duration  in  Example  1  can  be  arbitrarily  long.  This  situation  can  be  partially 
remedied  if  transactions  are  not  allowed  to  be  preempted;  however,  this  solution  is  only  ap¬ 
propriate  for  very  short  transactions,  because  it  creates  unnecessary  blocking.  For  instance, 
once  a  long,  low-priority  transaction  starts  execution,  a  high-priority  transaction  not  requiring 
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access  to  the  same  set  of  data  objects  may  be  needlessly  blocked.1  An  objective  of  this 
paper  is  to  design  an  appropriate  priority  management  protocol  for  a  given  concurrency  con¬ 
trol  protocol  so  that  deadlocks  can  be  avoided  and  the  duration  of  blocking  can  be  tightly 
bounded. 


^The  priority  inversion  problem  was  first  discussed  by  Lampson  and  Redall  [9]  in  the  context  of  monitors.  They 
suggest  that  each  monitor  always  be  executed  at  a  priority  level  higher  than  all  tasks  that  would  ever  call  the 
monitor. 
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2.  The  Read-  or  Write-Priority  Ceiling  Protocol 


2.1.  Basic  Concepts 

Real-time  databases  are  often  used  by  applications  such  as  tracking.  Since  tracking  opera¬ 
tions  consist  of  both  signal  processing  and  database  accessing,  we  assume  that  each  in¬ 
stance  of  a  periodic  task  consists  of  data-processing  code  and  embedded  transactions 
operating  on  the  database.  We  assume  that  an  embedded  transaction  consists  of  a  se¬ 
quence  of  read  and  write  operations  operating  upon  the  database.  A  task  can  have  multiple 
embedded  transactions.  However,  embedded  transactions  in  a  task  do  not  overlap.  Each 
embedded  transaction  will  follow  the  two-phase  lock  protocol  [6],  which  requires  a  trans¬ 
action  to  acquire  all  the  locks  before  it  releases  any  lock.  Once  a  transaction  releases  a 
lock,  it  cannot  acquire  any  new  lock. 

In  this  section,  we  also  assume  that  all  the  tasks  are  periodic,  which  models  the  periodic 
operation  of  sensors.  In  addition,  we  assume  that  the  database  resides  in  the  main  memory. 
We  will,  however,  relax  both  assumptions  in  the  next  section.  When  tasks  are  periodic,  we 
assume  that  their  priorities  are  assigned  by  the  rate  monotonic  algorithm  in  which  a  shorter 
period  task  has  a  higher  priority.  It  was  shown  in  [15]  that  the  rate  monotonic  algorithm  is  an 
optimal  static-priority  scheduling  algorithm  for  periodic  tasks.  A  high-priority  task  will  preempt 
the  execution  of  lower  priority  tasks  unless  it  is  blocked  by  the  read-  or  write-priority  ceiling 
protocol  defined  later  in  this  report. 

With  only  two-phase  locking  and  priority  assignment,  we  can  encounter  the  problem  of  un¬ 
bounded  priority  inversion  as  illustrated  in  Example  1.  However,  the  idea  of  priority  in¬ 
heritance  [24]  solves  the  unbounded  priority  inversion  problem.  In  the  context  of  preemptive 
scheduling,  a  higher  priority  task  x  can  preempt  the  execution  of  lower  priority  tasks  unless  x 
is  blocked  by  the  locking  protocol.  The  priority  inheritance  rule  states  that  when  the  trans¬ 
action  of  task  x  blocks  the  execution  of  higher  priority  tasks,  it  executes  (inherits)  at  the 
highest  priority  of  all  the  tasks  blocked  by  x.  To  illustrate  this  idea,  let  us  apply  this  protocol 
to  Example  1.  Suppose  that  task  x1  is  blocked  by  task  x3.  The  priority-inheritance  protocol 
requires  task  x3  to  execute  its  transaction  at  the  priority  of  task  x-|  until  it  releases  the  lock  on 
data  object  O.  As  a  result,  task  x2  will  be  unable  to  preempt  x3.  Once  task  x3  unlocks  data 
object  O,  it  returns  to  its  assigned  priority  and  will  immediately  be  preempted  by  .  As  we 
can  see,  this  simple  priority-inheritance  idea  reduces  the  blocking  time  of  a  higher  priority 
task  from  the  entire  execution  time  of  lower  priority  tasks  to  only  the  duration  of  lower  priority 
tasks’  embedded  transactions. 

The  second  idea  is  a  total  priority  ordering  of  active  transactions.  A  transaction  embedded  in 
a  task  is  said  to  be  active  if  it  has  started  but  not  yet  completed  its  execution.  Thus  a  trans¬ 
action  can  be  active  in  one  of  two  ways:  executing  or  being  preempted  in  the  middle  of  its 
execution.  The  idea  of  a  total  priority  ordering  is  that  we  want  our  protocol  to  ensure  that 
each  active  transaction  is  executed  at  a  higher  priority  level,  taking  priority  inheritance  and 
the  read  and  write  semantics  into  consideration.  Together  with  the  first  idea,  we  get  the 
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properties  of  freedom  from  deadlock  and  a  worst-case  blocking  of  at  most  a  single  em¬ 
bedded  transaction.  We  shall  refer  to  the  latter  property  as  the  block-at-most-once  property. 

To  ensure  the  total  priority  ordering  of  active  transactions,  we  define  three  parameters  for 
each  data  object  in  the  database:  the  write-priority  ceiling,  the  absolute  priority  ceiling  and 
the  read-  or  write-priority  ceiling.  The  write-priority  ceiling  of  a  data  object  O  is  simply  the 
priority  of  the  highest  priority  task  that  may  write  O.  The  absolute  priority  ceiling  of  O  is  the 
priority  of  the  highest  priority  task  that  may  read  or  write  O.  The  read-  or  write-priority  ceiling 
of  the  data  object  is,  however,  set  dynamically.  We  shall  use  the  rule  that  a  task  x  cannot 
read  or  write-lock  a  data  object  and  execute  its  transaction  unless  its  priority  is  higher  than 
the  highest  priority  read-  or  write-priority  ceiling  locked  by  tasks  other  than  x.  We  shall  refer 
to  this  rule  as  the  ceiling  rule. 

When  a  task  write-locks  a  data  object  O,  O  cannot  be  read  or  written  by  another  task.  To 
ensure  that,  we  can  set  the  read-  or  write-priority  ceiling  of  O  equal  to  its  absolute  priority 
ceiling.  Since  the  absolute  priority  ceiling  of  O  is  equal  to  the  priority  of  the  highest  priority 
task  that  may  either  read  or  write  O,  it  prevents  another  task  from  reading  or  writing  O  until 
the  lock  on  O  is  released.  Similarly,  when  a  task  read-locks  a  data  object  O,  O  cannot  be 
written  by  another  task.  To  ensure  this,  when  a  data  object  O  is  read-locked  by  a  trans¬ 
action,  we  set  the  read-  or  write-priority  ceiling  of  O  equal  to  the  write-priority  ceiling  of  O. 
Since  the  write-priority  ceiling  equals  the  priority  of  the  highest  priority  task  that  may  write  O, 
the  ceiling  rule  prevents  another  transaction  from  writing  O.  Read  transactions  with  priorities 
higher  than  the  write-priority  ceiling  of  O  can  share  the  read-lock  on  O  however.  On  the 
other  hand,  this  protocol  forbids  read  transactions  with  priorities  lower  than  or  equal  to  the 
write-priority  ceiling  of  O  from  sharing  the  read-lock  on  O.  This  is  important.  Should  we  allow 
these  low-priority  read  transactions  to  share  a  read-lock  on  O,  when  the  high-priority  write 
transaction  arrives  and  attempts  to  write  O,  it  has  to  wait  for  multiple  readers.  That  is,  a  task 
can  be  blocked  by  multiple  lower  priority  embedded  transactions.  As  we  shall  see  in 
Theorem  8,  longer  blocking  durations  lead  to  lower  schedulability. 

From  the  viewpoint  of  priority  management,  the  objective  of  the  read-  or  write-priority  ceiling 
is  to  ensure  that  each  embedded  transaction  is  executed  at  a  higher  priority  level  than  the 
priority  levels  which  can  be  inherited  by  preempted  transactions.  When  a  transaction  T 
write-locks  a  single  data  object  O,  the  read-  or  write-priority  ceiling  of  O  represents  the 
highest  priority  that  T  can  inherit  through  O.  For  example,  when  T  write-locks  O,  it  can  block 
the  highest  priority  task  xH  that  may  read  or  write  O  and  hence  inherit  the  priority  of  xH. 
Therefore,  the  read-  or  write-priority  ceiling  of  a  write-locked  object  is  defined  to  be  equal  to 
the  absolute  priority  ceiling.  Alternatively,  let  a  low-priority  transaction  hold  a  read-lock  on  a 
data  object  O  and  let  transaction  Tw  be  the  highest  priority  transaction  that  may  request  a 
write-lock  on  O.  Transaction  T  can  block  xw  and  inherit  the  priority  of  xw.  Therefore,  the 
read-  or  write-priority  ceiling  of  a  read-locked  data  object  is  defined  as  the  data  object’s 
write-priority  ceiling. 

Under  the  read-  or  write-priority  ceiling  protocol,  a  task  x  cannot  acquire  a  lock  and  execute 
its  embedded  transaction  unless  its  priority  is  higher  than  all  the  read-  or  write-priority  ceil- 
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ings  of  the  data  object  locked  by  tasks  other  than  x.  Since  the  highest  read-  or  write-priority 
ceiling  of  the  locked  data  objects  represents  the  highest  priority  level  that  the  currently  active 
transactions  can  execute  (inherit),  we  ensure  that  the  transaction  of  x  executes  at  a  priority 
level  higher  than  all  the  preempted  transactions,  should  x  be  able  to  execute  its  transaction. 

Such  total  priority  ordering  of  active  transactions  leads  to  some  interesting  behavior.  For 
example,  the  read-  or  write-priority  ceiling  protocol  may  forbid  a  transaction  from  locking  an 
unlocked  data  object.  At  first  sight,  this  seems  to  introduce  unnecessary  blocking.  How¬ 
ever,  this  is,  in  fact,  the  "insurance  premium"  for  preventing  mutual  deadlock  and  the  block- 
at-most-once  property. 

Example  2:  Suppose  that  we  have  three  tasks,  x0,  x1t  and  x2,  arranged  in  descending  order 
of  priority.  In  addition,  there  are  two  data  objects  01  and  02. 

Xq  =  { •  •  • ,  write-tock{0^,  •  •  • ,  unlocKOJ,  •  •  • } 

Xj  =  { •  •  • ,  read-lock(0{),  •  •  • ,  write-locktp^),  •  •  • ,  unlock(02),  •  •  • ,  unlock(0{),  •  •  • ) 

Xj  =  { •  •  • ,  read-lock(Oj),  •  •  • ,  write-lock(0{),  ■  ■  • ,  untocKO{),  •  •  • ,  unlocKQ^,  •  •  • ) 

The  sequence  of  events  described  in  Example  2  is  depicted  in  Figure  2-2.  A  line  at  a  low 

level  Indicates  that  the  corresponding  task  is  blocked  or  has  been  preempted  by  a  higher 
priority  task.  A  line  raised  to  a  higher  level  indicates  that  the  task  is  executing.  The  absence 
of  a  line  indicates  that  the  task  has  not  yet  arrived  or  has  completed.  Shaded  portions  in¬ 
dicate  execution  of  transactions. 

First,  we  establish  the  priority  ceiling  of  each  of  the  data  objects.  The  write-priority  ceiling 
and  absolute  priority  ceiling  for  data  object  01  are  the  priorities  of  tasks  x2  and  x1 ,  P2  and 
Pv  respectively.  For  data  object  02,  both  the  write  and  absolute  priority  ceiling  are  equal  to 
Pv  For  data  object  O0,  both  ceilings  are  equal  to  P0. 

Suppose  that  at  time  t^,  task  x2  starts  its  execution.  At  time  f1t  x2  has  executed  read-lock 
(02)  and  the  read-  or  write-priority  ceiling  of  02  is  set  at  the  write-priority  ceiling  of  02,  i.e., 
Pv  Having  locked  02,  task  x2  starts  executing  its  embedded  transaction  T2.  At  this  instant, 
task  x1  is  initiated  and  preempts  transaction  T2.  However,  when  task  x1  tries  to  execute  its 
embedded  transaction  at  time  ^  by  making  an  indivisible  system  call  to  execute  read-lock 
(O.,),  the  scheduler  will  find  the  priority  of  P1  of  task  x1  is  not  higher  than  the  read-  or  write- 
priority  ceiling  of  locked  data  object  02,  which  was  set  at  Pv  Hence,  the  scheduler 
suspends  transaction  x1  without  letting  it  lock  Note  that  X-,  is  blocked  outside  its  em¬ 
bedded  transaction.  Transaction  T2  now  inherits  the  priority  of  task  x1  and  resumes  execu¬ 
tion.  Since  x1  is  denied  the  lock  on  O.,  and  suspended  instead,  a  potential  deadlock  be¬ 
tween  T1  and  T2  is  prevented.  If  x1  were  granted  the  lock  on  Ov  then  x.,  would  later  wait  for 
x2  to  release  the  lock  on  02,  while  x2  would  wait  for  x1  to  release  the  lock  on  01 . 

On  the  other  hand,  suppose  that  at  time  f3,  while  T2  is  still  in  its  transaction,  the  highest 
priority  task  x0  arrives  and  attempts  to  write-lock  data  object  O0.  Since  the  priority  of  x0  is 
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Figure  2-1 :  Sequence  of  Events  described  in  Example  2. 

higher  than  the  read-  or  write-priority  ceiling  of  locked  data  object  02,  task  x0's  transaction 
T0  will  be  granted  the  lock  on  the  data  object  O0.  Task  x0  will  therefore  continue  and  execute 
its  transaction,  thereby  effectively  preempting  T2  in  its  transaction  and  not  encountering  any 
blocking.  At  time  f4,  T0  completes  execution  and  T2  is  awakened,  for  T1  is  blocked  by  T2.  T2 
continues  execution  and  write-locks  Ov  At  time  %,  T2  releases  Ov  At  time  %,  when  T2 
releases  02,  task  x2  resumes  its  assigned  priority.  Now  T-,  is  signaled.  Having  a  higher 
priority,  it  preempts  T2  and  completes  execution.  Finally,  T2  resumes  and  completes. 

Note  that  in  the  above  example,  x0  is  never  blocked.  x1  was  blocked  by  the  lower  priority 
task  x2  during  the  intervals  [f2,  f3]  and  [f4,  fg].2  However,  these  two  intervals  correspond  to 


2The  interval  [tj,  f4]  is  not  considered  blocking  for  t1  since  it  wets  only  preempted  by  the  higher  priority  task  t0. 
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the  duration  that  T2  needs  to  lock  the  two  data  objects.  Thus,  the  blocking  duration  of  t1  is 
equal  to  the  duration  of  a  single  embedded  transaction  of  a  lower  priority  transaction  T2, 
even  though  the  actual  blocking  occurs  over  disjointed  time  intervals.  It  is,  indeed,  a  prop¬ 
erty  of  this  protocol  that  any  task  x  can  be  blocked  by,  at  most,  one  lower  priority  embedded 
transaction  until  x  suspends  itself  or  completes. 


2.2.  Definitions  and  Properties 

Having  reviewed  the  basic  concepts,  we  now  review  our  assumptions  and  state  the  notation 
used.  We  assume  that  we  are  given  a  centralized  database  system  and  there  is  a  set  of 
periodic  tasks.  In  addition,  we  assume  that  all  the  data  objects  reside  in  the  main  memory. 
Since  tracking  operations  consist  of  both  signal  processing  and  database  accessing,  we  as¬ 
sume  that  each  instance  of  a  periodic  task  executes  signal  processing  codes  and  embedded 
transactions.  We  assume  that  the  rate-monotonic  algorithm  is  used  to  assign  a  priority  to 
each  task.  This  algorithm  assigns  higher  priorities  to  tasks  with  shorter  periods  and  is  an 
optimal  static-priority  algorithm  for  periodic  tasks  [15].  If  two  tasks  are  ready  to  run  on  a 
processor,  the  higher  priority  task  will  run.  Equal  priority  tasks  are  run  in  a  FCFS  (first  come, 
first  served)  order.  We  also  assume  that  a  transaction  does  not  attempt  to  lock  an  object 
that  it  has  already  locked  and  thus  deadlock  with  itself.  We  also  assume  that  either  multiple 
read-locks  or  a  single  write-lock  can  be  held  on  a  data  object. 

Notation:  We  denote  the  given  tasks  as  an  ordered  set  {xv  •  •  • ,  xn}  where  the  tasks  are 
listed  in  descending  order  of  priority,  with  x1  having  the  highest  priority. 

Notation:  We  use  Tj j  to  denote  an  embedded  transaction  of  task  tj.  We  will  also  use  the 
simplified  notation  Tj’when  the  identity  of  y'is  not  important. 

Notation:  We  use  the  notation  P{  to  denote  the  priority  of  task  Xj. 

Definition:  The  lock  on  a  data  object  can  either  be  a  read-lock  or  a  write-lock.  A  task  x  that 
holds  a  read-lock  (write-lock)  on  a  data  object  O  is  said  to  have  read-locked  (write-locked) 
object  O.  The  write-priority  ceiling  of  a  data  object  is  defined  as  the  priority  of  the  highest 
priority  task  that  may  write  this  object.  The  absolute  priority  ceiling  is  defined  as  the  priority 
of  the  highest  priority  task  that  may  either  read  or  write  this  data  object.  When  a  data  object 
O  is  write-locked,  the  read-  or  write-priority  ceiling  of  O  is  defined  to  be  equal  to  the  absolute 
priority  ceiling  of  O.  When  a  data  object  O  is  read-locked,  the  read-  or  write-priority  ceiling 
of  O  is  defined  to  be  equal  to  the  write  priority  ceiling  of  O. 

Having  stated  our  objectives  and  our  assumptions,  we  now  define  the  read-  or  write-priority 
ceiling  protocol. 

1.  Task  x,  having  the  highest  priority  among  the  tasks  ready  to  run,  is  assigned 
the  processor.  Before  task  x  starts  to  execute  an  embedded  transaction  T, 
task  x  must  first  obtain  the  locks  on  the  data  objects  that  it  accesses.  In  addi¬ 
tion,  each  embedded  transaction  follows  the  two-phase  lock  protocol  and  all 
the  locks  will  be  released  at  the  end  of  the  transaction. 
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2.  Let  0H  be  the  data  object  with  the  highest  read-  or  write-priority  ceiling  of  all 
data  objects  currently  locked  by  transactions  other  than  those  of  x.  When  the 
transaction  of  task  x  attempts  to  lock  a  data  object  O,  x  will  be  blocked  and  the 
lock  on  an  object  O  will  be  denied,  if  the  priority  of  task  x  is  not  higher  than  the 
read-  or  write-priority  ceiling  of  data  object  0|_|.  In  this  case,  task  x  is  said  to  be 
blocked  by  the  task  whose  transaction  holds  the  lock  on  0H.  If  the  priority  of 
task  x  is  higher  than  the  read-  or  write-priority  ceiling  of  0H,  then  x  is  granted 

the  lock  on  O3. 

3.  A  task  x  and  its  transaction  T  uses  the  priority  assigned  to  x,  unless  T  blocks 
higher  priority  transactions.  If  transaction  T  blocks  higher  priority  tasks,  T 
inherits  PH,  the  highest  priority  of  the  tasks  blocked  by  T.  Priority  inheritance  is 
transitive.  Finally,  the  operations  of  priority  inheritance  and  of  the  resumption 
of  original  priority  must  be  indivisible. 

4.  When  a  task  x  does  not  attempt  to  execute  an  embedded  transaction,  it  can 
preempt  other  tasks  and  their  embedded  transactions  executing  at  a  lower  pri¬ 
ority  level. 

Remark:  Under  this  protocol,  we  need  not  explicitly  check  for  the  possibility  of  read-write 
conflicts.  For  instance,  when  an  object  O  is  write-locked  by  a  task  x,  the  read-  or  write- 
priority  ceiling  of  O  is  equal  to  the  priority  of  the  highest  priority  task  that  can  access  O. 
Hence,  the  protocol  will  block  a  higher  priority  task  that  may  want  to  write  or  read  O.  On  the 
other  hand,  suppose  that  the  object  O  is  read-locked  by  x.  Then,  the  read-  or  write-priority 
ceiling  of  O  is  equal  to  the  highest  priority  task  that  may  write  O.  Hence,  a  task  that  attempts 
to  write  O  will  have  a  priority  no  higher  than  the  read-  or  write-priority  ceiling  and  will  be 
blocked.  Only  the  tasks  that  read  O  and  have  priority  higher  than  the  read-  or  write-priority 
ceiling  will  be  allowed  to  read-lock  O,  and  read-locks  are  compatible. 

Under  the  read-  or  write-priority  ceiling  protocol,  mutual  deadlock  of  transactions  cannot  oc¬ 
cur  and  each  task  can  be  blocked  by  at  most  one  embedded  transaction  until  it  completes  or 
suspends  itself.  We  shall  now  prove  both  these  properties  of  the  read-  or  write-priority  ceil¬ 
ing  protocol. 

Lemma  1:  Under  the  read-  or  write-priority  ceiling  protocol,  each  transaction  will 
execute  at  a  higher  priority  level  than  the  level  that  the  preempted  transactions 
can  inherit. 

Proof:  By  the  definition  of  the  read-  or  write-priority  ceiling  protocol,  when  a  task  x 
locks  a  set  of  data  objects,  the  highest  priority  level  x  can  inherit  is  equal  to  the 
highest  read-  or  write-priority  ceiling  of  the  data  objects  locked  by  x.  Hence,  when 
the  priority  of  task  xH  is  higher  than  the  highest  read-  or  write-priority  ceiling  of  the 
data  objects  locked  by  a  transaction  T  of  task  x,  the  transactions  of  xH  will  execute 
at  a  priority  that  is  higher  than  the  preempted  transaction  T  can  inherit. 

Theorem  2:  There  is  no  mutual  deadlock  under  the  read-  or  write-priority  ceiling 
protocol. 


3Under  this  condition,  there  will  be  no  read-write  conflict  on  the  object  O,  and  we  need  not  check  if  O  has  been 
locked.  See  the  remark  that  follows  the  protocol  definition. 
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Proof:  Suppose  that  a  mutual  deadlock  can  occur.  Let  the  highest  priority  of  all 
the  tasks  involved  in  the  deadlock  be  P.  Due  to  the  transitivity  of  priority  in¬ 
heritance,  all  the  tasks  involved  in  the  deadlock  will  eventually  inherit  the  same 
highest  priority  P.  This  contradicts  Lemma  1 . 

Lemma  3:  Under  the  read-  or  write-priority  ceiling  protocol,  until  task  x  either  com¬ 
pletes  its  execution  or  suspends  itself,  task  x  can  be  blocked  for  at  most  a  single 
embedded  transaction  of  a  lower  priority  task  xL,  even  if  xL  has  multiple  embedded 
transactions. 

Proof:  Suppose  that  task  x  is  blocked  by  a  lower  priority  task  xL.  By  Theorem  2, 
there  will  be  no  deadlock  and  hence  task  xL  will  exit  its  current  transaction  at  some 
instant  fv  Once  task  xL  exits  its  transaction  at  time  f1t  task  xL  is  preempted  by  x. 
Since  xL  is  no  longer  within  a  transaction,  it  cannot  inherit  a  higher  priority  than  its 
own  priority  unless  it  executes  another  transaction.  However,  xL  cannot  resume 
execution  until  x  completes  or  suspends  itself.  The  Lemma  follows. 

Theorem  4:  Under  the  read-  or  write-priority  ceiling  protocol,  a  task  x  can  be 
blocked  by  at  most  a  single  embedded  transaction  of  one  lower  priority  task  until 
either  x  completes  its  execution  or  suspends  itself. 

Proof:  Suppose  that  x  is  blocked  by  n  lower  priority  transactions.  Given  Lemma 

3,  x  must  be  blocked  by  the  transactions  of  n  different  lower  priority  tasks,  x1 . 

xn,  where  the  priority  of  Xj  is  assumed  to  be  higher  than  or  equal  to  that  of  xj+1 . 
Under  the  protocol,  a  task  not  in  a  transaction  can  always  be  preempted  by  a 
higher  priority  task.  Hence,  a  lower  priority  task  cannot  block  a  higher  priority  task 

unless  it  is  already  in  its  transaction.  Therefore,  tasks  x1 . xn  must  be  in  their 

transactions  when  x  arrives.  By  assumption,  x  is  blocked  by  xn  and  xn  inherits  the 
priority  of  x.  Since  x  can  be  blocked  by  xn,  the  priority  of  task  x  cannot  be  higher 
than  the  highest  priority  P  that  can  be  inherited  by  xn.  On  the  other  hand,  by 
Lemma  1 ,  the  priority  of  task  xn_.,  is  higher  than  P.  It  follows  that  the  priority  of  task 
xn_.|  is  higher  than  that  of  task  x.  This  contradicts  the  assumption  that  the  priority 
of  x  is  higher  than  that  of  tasks  x1 . xn. 

Corollary  5:  If  a  task  Xj  suspends  itself  at  most  k  times,  then  the  above  theorem 
holds  with  the  duration  of  blocking  equal  to  k+1  embedded  transactions. 

Remark:  The  read-  or  write-priority  ceiling  protocol  is  selectively  restrictive  on  the  sharing  of 
read-locks.  The  reason  is  that  a  direct  application  of  the  read  and  write  semantic  can  lead 
to  prolonged  durations  of  blocking.  For  example,  suppose  that  we  have  a  single  write  trans¬ 
action  at  the  highest  priority  level  and  ten  lower  priority  read  transactions.  If  we  let  ten  trans¬ 
actions  concurrently  hold  read-locks  on  data  object  O,  then  when  a  higher  priority  task  ar¬ 
rives  later  and  attempts  to  write  O,  it  has  to  wait  for  all  ten  of  these  transactions  to  complete. 
That  is,  some  forms  of  concurrency  can  lengthen  the  worst-case  duration  of  blocking,  result¬ 
ing  in  poorer  schedulability. 

We  now  develop  a  set  of  sufficient  conditions  under  which  a  set  of  periodic  tasks  with  hard 
deadlines  at  the  end  of  the  periods  can  be  scheduled  by  the  rate-monotonic  algorithm  [15] 
when  the  read-  or  write-priority  ceiling  protocol  is  used. 

Liu  and  Layland  propose  the  following  theorem,  which  was  proved  under  the  assumption  of 
independent  tasks;  i.e.,  there  is  no  blocking  due  to  data  sharing  and  synchronization. 
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Theorem  6:  A  set  of  n  periodic  tasks  scheduled  by  the  rate-monotonic  algorithm 
can  always  meet  their  deadlines  if 

C  i  C_  . , 

_*+•••  +  —  <n(2lln-l) 

Tl  Tn 

where  Cj  and  Tj  are  the  execution  time  and  period  of  task  xf  respectively. 

Theorem  6  offers  a  sufficient  (worst-case)  condition  that  characterizes  the  rate-monotonic 
schedu lability  of  a  given  periodic  task  set.  An  exact  characterization  of  rate-monotonic 
schedu lability  can  be  found  in  [12]. 

When  tasks  are  independent  of  one  another  and  do  not  access  shared  data,  Theorem  6 
provides  us  with  the  condition  under  which  a  set  of  n  periodic  tasks  can  be  scheduled  by  the 
rate-monotonic  algorithm.4  Although  this  theorem  takes  into  account  the  effect  of  a  task 
being  preempted  by  higher  priority  tasks,  it  does  not  consider  the  effect  of  blocking  caused 
by  lower  priority  tasks  upon  schedulability  analysis.  We  now  consider  the  effect  of  blocking. 

Theorem  7:  A  lower  priority  write  transaction  Tw  can  block  a  higher  priority  task  x 
with  priority  P,  if  and  only  if  Tw  may  write-lock  a  data  object  whose  absolute  prior¬ 
ity  ceiling  is  higher  than  or  equal  to  P.  A  lower  priority  read  transaction  Tr  can 
block  a  higher  priority  task  x  with  priority  P,  if  and  only  if  Tr  may  read-lock  a  data 
object  whose  write-priority  ceiling  is  higher  than  or  equal  to  P. 

Proof:  It  directly  follows  from  the  definitions  of  the  read-  or  write-priority  ceiling 
protocol. 

Let  Z  be  the  set  of  embedded  transactions  that  could  block  task  x.  By  Theorem  4,  task  x 
can  be  blocked  for  at  most  the  duration  of  a  single  element  in  Zif  it  does  not  suspend  itself. 
Hence  the  worst-case  blocking  time  for  x  is  the  duration  of  the  longest  embedded  trans¬ 
action  in  Z  when  x  does  not  suspend  itself.  If  the  task  x  suspends  itself  k  times,  then  the 
worst-case  blocking  time  is  equal  to  the  sum  of  the  k+1  longest  elements  in  Z.  We  denote 
this  worst-case  blocking  time  of  task  xs  as  Bj.  Note  that  given  a  set  of  n  periodic  tasks,  Bn  = 
0,  since  there  is  no  lower  priority  task  to  block  xn. 

Theorem  6  can  now  be  generalized  in  a  straightforward  fashion.  In  order  to  test  the 
schedulability  of  xif  we  need  to  consider  both  the  preemptions  caused  by  higher  priority 
tasks  and  blocking  by  lower  priority  tasks,  along  with  the  utilization  of  x;.  The  blocking  of  any 
instance  of  Xj  is  bounded  by  Bj.  Thus,  Theorem  6  becomes 


Theorem  8:  Suppose  that  a  task  does  not  suspend  itself  from  initiation  to  comple¬ 
tion.  A  set  of  n  periodic  tasks  using  the  read-  or  write-priority  ceiling  protocol  can 
be  scheduled  by  the  rate  monotonic  algorithm  if  the  following  conditions  are  satis¬ 
fied: 


4That  is,  the  conditions  under  which  all  the  instances  of  all  the  n  tasks  will  meet  their  deadlines. 
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Proof:  Suppose  that  for  each  task  xs  the  inequality  is  satisfied.  It  follows  that  the 
inequality  of  Theorem  6  will  also  be  satisfied  with  n  =  i  and  Cj  replaced  by  Cj  j  = 

(Cj  +  Bj).  That  is,  in  the  absence  of  blocking,  any  instance  of  task  Xj  will  still  meet 
its  deadline  even  if  it  executes  for  (Cj  +  Bj)  units  of  time.  It  follows  that  task  xjP  if  it 
executes  for  only  Cj  units  of  time,  can  be  delayed  by  S,  units  of  time  and  still  meet 
its  deadline.  Hence  the  theorem  follows. 

Remark:  The  first  /  terms  in  the  above  inequality  constitute  the  effect  of  preemptions  from  all 
higher  priority  tasks  and  the  execution  time  of  xjt  while  Bj  of  the  last  term  represents  the 
worst  case  blocking  time  due  to  all  lower  priority  tasks  for  one  instance  of  task  x(. 

Corollary  9:  A  set  of  n  periodic  tasks  using  the  read-  or  write-priority  ceiling 
protocol  can  be  scheduled  by  the  rate  monotonic  algorithm  If  the  following  con¬ 
dition  is  satisfied: 


Proof:  Since  n(2l^n-l)^i(2^l-l)  and  maxQ- ,  •  • 
then  all  the  inequalities  in  Theorem  8  also  hold. 


b. 


if  this  inequality  holds 
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3.  Performance  Evaluation 


In  the  previous  section,  we  have  assumed  that  all  the  tasks  are  periodic  and  that  all  the 
database  objects  are  in  the  main  memory.  In  this  section,  we  relax  these  two  assumptions 
and  examine  the  performance  of  read-  or  write-priority  ceiling  protocol  versus  the  perfor¬ 
mance  of  the  two-phase  lock  protocol  with  and  without  priority  assignments  to  tasks.  This 
experiment  investigates  the  performance  of  the  performance  characteristics  in  a  single-site 
database  system,  using  the  University  of  Virginia’s  database  prototyping  tool  [25].  In  this 
experiment,  we  assume  that  the  transaction  system  is  a  soft  real-time  system,  in  the  sense 
that  we  do  not  guarantee  the  transaction  deadlines.  However,  each  transaction  has  a  dead¬ 
line  and  we  assume  that  there  will  be  no  value  in  completing  a  transaction  once  it  has 
missed  its  deadline.  Transactions  that  miss  the  deadline  are  aborted,  and  disappear  from 
the  system  immediately  with  some  abort  cost.  In  this  experiment,  each  task  consists  of  a 
single  transaction  with  an  execution  profile  that  alternates  database  access  requests  with 
equal  computation  requests,  and  some  processing  requirement  for  termination  (either  com¬ 
mit  or  abort).  Thus  the  total  processing  time  of  a  transaction  is  directly  related  to  the  num¬ 
ber  of  data  objects  accessed. 

In  the  experiments,  transactions  are  generated  with  exponentially  distributed  interarrival 
times,  and  the  data  objects  updated  by  a  transaction  are  chosen  uniformly  from  the  data¬ 
base.  Due  to  space  considerations,  we  cannot  present  all  our  results  but  have  selected  the 
graphs  which  best  illustrate  the  difference  and  performance  of  the  algorithms.  For  example, 
we  have  omitted  the  results  of  an  experiment  that  varied  the  size  of  the  database,  and  thus 
the  number  of  conflicts.  This  is  because  they  only  confirm  and  do  not  increase  the  knowl¬ 
edge  yielded  by  other  experiments.  The  measure  of  merit  Is  the  throughput  and  the  per¬ 
centage  of  transactions  that  miss  their  deadlines.  The  measure  of  throughput  is  records 
accessed  per  second  for  successful  transactions,  not  in  transactions  per  second.  This  is  to 
account  for  the  fact  that  bigger  transactions  need  more  database  processing. 

For  each  experiment  and  for  each  algorithm  tested,  we  collected  performance  statistics  and 
averaged  over  1 0  runs.  We  have  used  the  transaction  size  (the  number  of  data  objects  a 
transaction  needs  to  access)  as  one  of  the  key  variables  in  the  experiments.  It  varies  from  a 
small  fraction  up  to  a  relatively  large  portion  (10%)  of  the  database  so  that  conflict  would 
occur  frequently.  The  high  conflict  rate  allows  synchronization  protocols  to  play  a  significant 
role  in  the  system  performance.  We  chose  the  arrival  rate  so  that  protocols  are  tested  in  a 
heavily  loaded  system,  because  when  designing  real-time  systems,  one  must  consider  high- 
load  situations.  Even  though  high-load  situations  may  not  arise  frequently,  one  would  like  to 
have  a  system  that  misses  as  few  deadlines  as  possible  when  the  system  is  under 
stress  [1], 

In  Figures  3-1  and  3-2,  the  throughput  of  the  priority-ceiling  protocol  (C),  the  two-phase  lock¬ 
ing  protocol  with  priority  mode  (P),  and  the  two-phase  locking  protocol  without  priority  mode 
(L),  is  shown  for  transactions  of  different  sizes  with  balanced  workload  and  I/O  bound  work¬ 
load.  The  two  important  factors  affecting  the  performance  of  locking  protocols  are  their  abili¬ 
ties  to  resolve  the  locking  conflicts  and  to  perform  the  I/O  and  transactions  in  parallel.  When 
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the  transaction  size  is  small,  there  is  little  locking  conflict  and  the  problem  such  as  deadlock 
and  priority  inversion  has  little  effect  upon  the  overall  performance  of  a  locking  protocol.  On 
the  other  hand,  when  transaction  size  becomes  large,  the  probability  of  locking  conflict  rises 
rapidly.  In  fact,  the  probability  of  deadlocks  goes  up  with  the  fourth  power  of  the  transaction 
size  [8].  Hence,  we  would  expect  that  the  performance  of  protocols  will  be  dominated  by 
their  abilities  to  handle  locking  conflicts  when  transaction  size  is  large. 


0  4  8  12  16  20  24 

Transaction  size 


Figure  3-1 :  Balanced  Workload 

As  illustrated  in  Figures  3-1  and  3-2,  the  performance  of  the  two-phase  lock  algorithm,  with 
or  without  priority  assignments  to  transactions,  degrades  very  fast  when  transaction  size  in¬ 
creases.  This  can  be  attributed  to  the  inability  of  this  protocol  to  prevent  deadlock  and  prior¬ 
ity  inversions.  On  the  other  hand,  the  read-  or  write-priority  ceiling  protocol  handles  locking 
conflicts  very  well.  The  protocol  is  free  from  deadlocks  and  exhibits  the  block-at-most-once 
property.  Hence,  this  protocol  performs  much  better  than  the  two-phase  lock  protocol  when 
the  transaction  size  is  large.  The  main  weakness  of  the  read-  or  write-priority  ceiling 
protocol  is  its  inability  to  perform  I/O  and  transactions  in  parallel.  For  example,  suppose  that 
transaction  T  has  locked  O.,  and  it  now  wants  to  lock  data  object  02.  Unfortunately,  02  is 
not  in  the  main  memory.  As  a  result,  T  is  suspended.  However,  neither  are  transactions 
with  priorities  lower  than  the  read-  or  write-priority  ceiling  of  01  allowed  to  execute.  This 
could  lead  to  the  idling  of  the  processor  until  either  02  is  transferred  to  the  main  memory  or 
a  transaction  whose  priority  is  higher  than  the  read-  or  write-priority  ceiling  arrives.  We  call 
this  I/O  blocking.  When  transaction  size  is  small,  the  locking  conflict  rate  is  small.  Hence, 
the  two-phase  lock  performs  well.  However,  due  to  I/O  blocking  the  throughput  of  read-  or 
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Figure  3-2:  I/O  Bounded  Workload 

write-priority  ceiling  protocol  is  not  as  good  as  that  of  two-phase  lock  protocol,  especially 
when  the  workload  is  I/O  bounded. 

Since  I/O  cost  is  one  of  the  key  parameters  in  determining  performance,  we  have  investi¬ 
gated  an  approach  to  improve  system  performance  by  performing  the  I/O  operation  before 
locking.  This  is  called  the  intention  I/O.  In  the  intention  mode  of  I/O  operation,  the  system 
"pre-fetches"  data  objects  that  are  in  the  access  lists  of  transactions  submitted,  without  lock¬ 
ing  them.  This  approach  will  reduce  the  locking  time  of  data  objects,  resulting  in  higher 
throughput.  As  shown  in  Figure  3-3,  intention  I/O  improves  throughput  of  both  the  two- 
phase  locking  and  the  ceiling  protocol.  However,  improvement  in  the  ceiling  protocol  is 
much  more  significant.  This  is  because  intention  I/O  effectively  solves  the  I/O  blocking  prob¬ 
lem  of  the  read-  or  write-priority  ceiling  protocol. 

Another  important  performance  statistic  is  the  percentage  of  transactions  missing  deadlines, 
since  the  synchronization  protocol  in  real-time  database  systems  should  satisfy  the  timing 
constraints  of  individual  transactions.  In  our  experiments,  each  transaction’s  deadline  is  set 
proportional  to  its  size  and  system  workload  (number  of  transactions),  and  the  transaction 
with  the  shorter  deadline  is  assigned  a  higher  priority.  As  shown  in  Figure  3-4,  the  percent¬ 
age  of  transactions  missing  deadlines  increases  sharply  for  the  two-phase  locking  protocol 
as  the  transaction  size  increases  due  to  the  protocol’s  inability  to  deal  with  deadlock  and  to 
give  preference  to  transactions  with  shorter  deadlines.  Two-phase  lock  with  priority  assign¬ 
ment  performs  somewhat  better,  because  the  timing  constraints  of  transactions  are  consid- 
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Figure  3-3:  With  Intention  I/O 

ered,  although  the  deadlock  and  priority-inversion  problems  still  handicap  performance.  The 
read-  or  write-priority  ceiling  protocol  has  the  best  relative  performance  because  it  ad¬ 
dresses  both  the  deadlock  and  priority-inversion  problem. 
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Figure  3-4:  Percentage  of  Missing  Deadline 
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4.  Conclusions 

Real-time  database  is  an  important  area  of  research,  with  applications  ranging  from  surveil¬ 
lance  to  reliable  manufacturing  and  production  control.  In  this  paper,  we  have  investigated 
the  read-  or  write-priority  ceiling  protocol,  which  integrates  the  two-phase  lock  protocol  with 
priority-driven  real-time  scheduling.  We  have  shown  that  this  protocol  is  free  from  mutual 
deadlock  and  that  a  task  x  can  be  blocked  for  at  most  the  duration  of  a  single  embedded 
transaction  of  a  lower  priority  task  until  x  suspends  itself  or  completes.  We  have  also  devel¬ 
oped  schedulability  bounds  for  periodic  tasks  in  a  centralized  in-core  database.  Finally,  we 
experimentally  evaluated  the  performance  of  this  protocol  when  the  tasks  are  invoked 
aperiodically  and  the  database  is  no  longer  in-core. 
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